Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# About User-Managed Media Recovery Problems

Table 21-1, "Media Recovery Problems" describes potential problems that can occur during media recovery.

Table 21-1 Media Recovery Problems

Problem | Description
--- | ---
Missing or misnamed archived log | Recovery stops because the database cannot find the archived log recorded in the control file.
When you attempt to open the database, error `ORA-1113` indicates that a datafile needs media recovery | This error commonly occurs because: You are performing incomplete recovery but failed to restore all needed datafile backups. Incomplete recovery stopped before datafiles reached a consistent SCN. You are recovering datafiles from an online backup, but not enough redo was applied to make the datafiles consistent. You are performing recovery with a backup control file, and did not specify the location of a needed online redo log. A datafile is undergoing media recovery when you attempt to open the database. Datafiles needing recovery were not brought online before executing `RECOVER` `DATABASE`, and so were not recovered.
Redo record problems | Two possible cases are as follows: Recovery stops because of failed consistency checks, a problem called stuck recovery. Stuck recovery can occur when an underlying operating system or storage system loses a write issued by the database during normal operation. The database signals an internal error when applying the redo. This problem can be caused by an Oracle bug. If checksums are not being used, it can also be caused by corruptions to the redo or data blocks.
Corrupted archived logs | Logs may be corrupted while they are stored on or copied between storage systems. If `DB_BLOCK_CHECKSUM` is enabled, then the database usually signals checksum errors. If checksumming is not on, then log corruption may appear as a problem with redo.
Archived logs with incompatible parallel redo format | If you enable the parallel redo feature, then the database generates redo logs in a new format. Prior releases of Oracle are unable to apply parallel redo logs. However, releases prior to Oracle9i Release 2 (9.2) can detect the parallel redo format and indicate the inconsistency with the following error message: `External` `error` `00303,` `00000,` `"cannot` `process` `Parallel` `Redo"`. See Also: Oracle Database Performance Tuning Guide to learn about the parallel redo feature
Corrupted data blocks | A datafile backup may have contained a corrupted data block, or the data block may become corrupted either during recovery or when it was copied to the backup. If checksums are being used, then the database signals a checksum error. Otherwise, the problem may also appear as a redo corruption.
Random problems | Memory corruptions and other transient problems can occur during recovery.

The symptoms of media recovery problems are usually external or internal errors signaled during recovery. For example, an external error indicates that a redo block or a data block has failed checksum verification checks. Internal errors can be caused by either bugs in the database or errors arising from the underlying operating system and hardware.

If media recovery encounters a problem while recovering a database backup, whether it is a stuck recovery problem or a problem during redo application, the database always stops and leaves the datafiles undergoing recovery in a consistent state, that is, at a consistent SCN preceding the failure. You can then do one of the following:

- Open the database read-only to investigate the problem.

- Open the database with the `RESETLOGS` option, as long as the requirements for opening `RESETLOGS` have been met. Note that the `RESETLOGS` restrictions apply to opening the standby database as well, because a standby database is updated by a form of media recovery.

In general, opening the database read-only or opening with the `RESETLOGS` option require all online datafiles to be recovered to the same SCN. If this requirement is not met, then the database may signal `ORA-1113` or other errors when you attempt to open. Some common causes of `ORA-1113` are described in Table 21-1, "Media Recovery Problems".

The basic methodology for responding to media recovery problems occurs in the following phases:

1. Try to identify the cause of the problem. Run a trial recovery if needed.

2. If the problem is related to missing redo logs or you suspect there is a redo log, memory, or data block corruption, then try to resolve it using the methods described in Table 21-2.

3. If you cannot resolve the problem using the methods described in Table 21-2, then do one of the following:

   - Open the database with the `RESETLOGS` option if you are recovering a whole database backup. If you have performed serial media recovery, then the database contains all the changes up to but not including the changes at the SCN where the corruption occurred. No changes from this SCN onward are in the recovered part of the database. If you have restored online backups, then opening `RESETLOGS` succeeds only if you have recovered through all the `ALTER` `...` `END` `BACKUP` operations in the redo stream.

   - Proceed with recovery by allowing media recovery to corrupt data blocks. After media recovery completes, try performing block media recovery using RMAN.

   - Call Oracle Support Services as a last resort.

     See Also: "Performing Disaster Recovery" to learn about block media recovery